By Lee Killough
>Hey, you guys, I need help! Howda hell do I make switches work?
>I want to press a switch that lifts something elsewhere, but I can't!
>The same thing with crushers and teleport...................................
>How do I manage to teleport to a new sector??????
Welcome to Sector Tags.
Each linedef has a number stored in it called a "sector tag". Sector tags are
used to identify the sectors that a linedef will operate on when activated.
Each sector also has a sector tag. That sector tag is used to "tag" the sector
with a particular number that can be used to identify it in action linedefs.
More than one sector can share the same sector tag, in which case all of the
sectors sharing the tag will be affected similarly when that tag is activated
by a linedef.
To make a teleporter work, you must draw teleporter linedefs (type 97) that
tell Doom that the line is a teleporter crossover point. Then you must draw
a sector where the teleporter will take the player (or monsters).
The teleporter linedef and teleporter destination sector must both be tagged
with the same tag, and is should not be 0. That way, when the player crosses
the linedef, Doom looks at the linedef's sector tag, and the looks for all
sectors sharing that same tag. In the case of a teleporter, you ordinarily
should only use one such sector (I've never tried teleporting to two sectors
at once -- uggh! I might come out in pieces!).
Finally, you must create a Teleporter Destination Thing in the destination
sector. This Thing tells Doom the player's location and direction when they
land at the teleporter's destination. It is similar to a player start.
teleporter
linedef
(type 97) teleporter
tag=1 destination
| sector, tag=1
| ------------------
| | |
| | * |
| | teleporter |
| | destination |
| | Thing |
| | |
------------------
By the way, sector tags are not to be confused with sector numbers.
For crushers, doors, lifts, etc., the idea is similar: you create a
linedef (either a switch, grab, or walk type), and you set its "sector
tag" to a value unique to this event, and not 0. Then you set the sector
you want it to affect to have a "sector tag" of the same value as the
linedef's "sector tag". When you walk over that line, or you press that
switch, or you shoot at the wall, you will be affecting the sectors
that have the same sector tag as that linedef has.
If you get the "no more plats" message and Doom crashes, it means you
tried to create a lift, but forgot to set the sector tag to something
other than 0. As a result, almost the entire level is selected, and Doom
cannot handle lowering the whole level as if it were one big elevator.
>hmm, a lot of my editors are going nutzoid or something, either producing >bad wads that crash or produce HOM and void blurs for absolutely no >reason. it may or may not have to do with the fact that my editors are for >1.666 and my game is 1.9, so i was just wondering if anyone knows where i >can pick up a free editor that works well with v1.9. just a few minutes >ago i made a wad with nothing but one small square sector, and even that >crashed. its so bad its not even funny. Oh, Doom requires at least two sectors. No kidding! Usually it won't crash, but I guess it does sometimes. I read about this requirement a long time ago, and I thought it was silly. It's really mentioned in one of the FAQs that a Doom level must have at least two sectors. I think it has to do with the nodes. Nothing has changed from 1.666->1.9 that should require differences in editors. I would make sure that your wad is not corrupted. If anything, version 1.9 should have fewer problems than 1.666. HOM that is not caused simply by missing textures (the newbie kind of bugs), is usually caused by long wide-open areas, similar to what can cause visplane overflows. You can add lines on the map parallel to the direction that the player is looking at when the problem is seen, and this sometimes fixes the problems, because what you are doing is making the node builder change its decisions on how to divide the map, and it tries to avoid breaking lines. So if you get HOM or visplane overflows, I would try changing the lines' and vertices' positions a little bit, tweak the node builder or use another one, and/or add extra two-sided "never on map" linedefs straight in the direction the player is looking when the problem occurs.
>I'm working on a Doom I map and haven't been able to make the "blocks >sound" flag work, or maybe I don't understand what it is supposed to do. >I can hear monsters, lifts, etc., across the line. Is it just supposed >to keep them from hearing you? Yes. It's only supposed to keep monsters from hearing the player. It takes two such linedefs to actually block the sound -- it will travel through one, however. Sounds that monsters hear travels between all two-sided lines except when floor and ceiling heights are such that the opening is completely blocked (like a closed door), or when the sound has reached a second "blocks sound" line. Note that sound always travels completely throughout a sector if it enters that sector, even if it is unconnected. So if you use the same sector in two different rooms, say for some furniture, then monsters in one room will hear you in the other, because sound will travel "through" the sector. By messing with the reject map, which is a table telling Doom whether monsters can see players from one sector while they are in another one, you can further disable monsters and even make them pacifists. The reject map affects their ability to see, and thus whether they will attack, but not their ability to hear. Whether a monster can hear a player is black-and-white -- only by using "blocks sounds" can you simulate a monster's hearing decreasing with distance from the player in an open area. If they can hear a player at all, then it does not matter at that point how far the player is. For players' sounds, simple linear distance is the only limiting factor. This means that if two rooms are next to each other, the player will always hear what's in the other room. However, closed doors and one-sided linedefs will decrease the sound a player hears. Crushing ceilings are especially easy to hear, even in other rooms blocked by walls or closed doors. The starting sounds of some monsters, such as the Cyberdemon and Mama Spider, are also heard throughout the entire level by the player. The "impassable" flag is another often-misunderstood one -- it simply means that neither monsters nor players can walk across the line. It does not stop weapons or stop anyone from seeing or hearing through it, however. "Blocks monsters," "Never on map," and "Always on map" are about the only self-explanatory linedef flags. The unpegged flags control how textures are drawn and the "lower unpegged" one is trickier than the upper "unpegged one" because the lower one affects normal sidedefs as well as lower ones, and its actual effect depends on a combination of factors including the ceiling height of the neighboring sector! "Secret" simply makes a line appear on the map as red line, the same as a 1-sided line looks. It does not have anything to do with secret percentage (which is actually controlled by a special sector type that tells Doom that an entire sector is secret). If a line is secret, it will not be revealed on the map as a different color, but nothing else is changed. "2s" means that normal textures can be seen through. This is the most confusing flag, because you can actually have a line with 2 sidedefs but without the 2s flag turned on. In this case, the side will be drawn just like a 1-sided one and it will have only its normal texture drawn, but rockets and plasma (and players) can go through it, even though bullets cannot go through it and monsters cannot see through it and thus will not even try to walk through it, although you can propel them through it with a rocket! Monsters cannot see through lines with the 2s flag cleared, but they can shoot through it, assuming they find a target in the same direction to shoot at.
>I'm having trouble with making an outdoor building. I think the ceiling is
>112. Every time I try to add a texture it leaves spaces.
If you are getting tutti-frutti, which means random colored debris on
walls, then you need to either check the y-offset or turn off the unpegged
flags (mostly in the case of a stairstep), or you need to choose a texture
that is 128 pixels high. Textures that are not exactly 128 pixels high
(the highest they can even be), are not able to be drawn correctly taller
than their own height.
If you are doing your own texture editing, then simply increase the size
of the texture to be 128 pixels high and use two patches instead of one,
with one of them filling up the gap left by the other one when the texture
is increased to 128 pixels high.
For outdoor buildings, you should contain the building entirely inside a
sector whose ceiling height is how high you want the building to look
from outside.
You should use one-sided linedefs that have their right sides pointing
out, for the outside walls that are not doors or windows. Do not use
two-sided lines everywhere because then you can shoot rockets through
them, the game will run more slowly, and other problems can happen.
If you add a window, turn the upper and lower unpegged flags on in the
window's linedef so that upper and lower textures line up with normal
textures of the adjacent walls (assuming the x-offset is correct).
Create a window sector between the inside and outside and set its
floor and ceiling heights to set the opening.
To align textures, use the unpegged attributes for windows as I said
above, but either use an editor that supports auto-alignment, or
compute the x offsets of the wall textures by adding up their lengths
and reducing them every time modulo the width of the texture. For
example, if the texture is 64 pixels wide:
len=70 len=40 len=60
*----------*-------*----------* -> left to right
sum 0 70 110 170
xoffs= 0 6 46 42
> 2 questions about some problems I'm having with textures. Nothing >fatal, but really ugly: > > 1. I have a long hallway with a crushing ceiling, and the only way >to get through it without becoming a red stain is to pass through a >two-sided linedef (which is NOT see-through) which is halfway down the >hall and take cover in a small sector until the ceiling raises again: > > > __ > ___________|_ | -----small sector you hide in > Exit| | > |____________ | > | | > | | > | | > | | > | | > |_| > > The problem is, the texture (SP_HOT1 if you needed to know) I used >to make the wall non see-throughable sort of "sinks" into the ground >when the ceiling starts lowering. You can still see the normal texture >while the "Wall Above" texture above it becomes visable. > > (I know, it doesn't make sense, maybe you've seen it before, >though). > Try playing with the "unpegged" attributes of the linedef. Briefly, here's what they do: Upper unpegged makes upper textures, which are the ones you see hanging down on a crushing ceiling, get drawn so that the top of the texture is at always at the ceiling. If you make your crushing ceiling upper unpegged, then it will look like it "stretches" to the ground rather than coming out from the ceiling. Lower unpegged makes lower textures get drawn so that the bottom of the texture is always a constant distance away from the ceiling no matter what floor height is, and it also makes lower textures line up with normal textures that are not unpegged but are next to it. If you make your crushing ceiling have "upper unpegged" linedefs then you will not see the textures moving while the ceiling is moving. If this cannot get it perfectly right, consider putting 2-sided linedefs right in front of each other, so that one stays constant and looks like a wall (but is walk-through) and the other one works with the crushing ceiling, door, or other effect.
> 2. I have a sector which is an open area (sky texture is used as a >ceiling). An adjascent sector, which is about 256 units higher, >provides one of the lower sector's wall (you got all that? :]) > > The higher sector has two height levels (which would really make it >two sectors) which are connected by a staircase: > _________________________________ > | | | | > | | Fl: | | > | | 320 | | > | |__________| | > | |__________| | > | |__________| | > | Floor: |__________| | > | 0 |__________| | > | | | > | | Floor: | > | | 256 | > | | | > | | | > ___________|____________________| > > The "Wall Below" texture that forms the right wall of the lower >sector is unalligned. I believe it's "WOOD3", but I wouldn't bet my >life on it. The wall looks like: > >_____________________________ > >______ >______ > __ > __ > __ > __ > __ > __ > __ > __ > ________________ > ________________ > > >______________________________ > > > (I love art) > > Is there any way I can allign the textures? (the misallignment >starts where the stairs are). Make the parts of the stairs around the sides of the walls (but not the steps) lower unpegged. This will make all of them line up at the bottom and they will also line up with normal textures on a wall nearby. Then change the x offsets of those lines so that the drawing of the texture starts correctly from step to step. For example, if the texture is 64 pixels wide and the step is 16 pixels wide, make the x offsets 0, 16, 32, 48, 0, 16, 32, 48, etc. You might consider getting Scott Amspoker's textures.doc file, located at: ftp.cdrom.com:/pub/doom/docs/editing. It explains the unpegged attributes in more detail.
>I get this problem when I run 2 or more .wads that total # of levels
>totals 13 or more.
>When I try to do this I get to play like the first 6 levels of a 9 level
>wad & the last 6 of a 12 level wad. Why does it do this & con I stop it
>from happening?
>
Are you trying to run several totally unrelated wad files at once?
If so, then it's unpredictable what will happen. Every wad file modifies
resources such as maps, textures, sounds, etc., and when more than one
wad is given on the command line (like -file wadfile1.wad wadfile2.wad ...),
then the last one takes precedence, for each resource. This means, for
example, if you have two wad files, and they both modify MAP01, then the
last one is the one that controls MAP01. But the music on MAP01 might be
determined by the first one, if the second one did not specify any music
for MAP01. Music, graphics, sprites, sound effects, textures, flats, levels,
etc. -- these are all resources that can be independently modified or
not by each wad file.
In general, you are not supposed to run several wad files at once, because
they will almost certainly conflict.
You can combine wad files, if you make sure that resources do not conflict,
but this must be done using editors or other utilities, not just the command
line.
The total number of levels does not depend on the wad files. It is determined
by the version and game of Doom you have. There are 27 levels in Doom 1, 32
in Doom 2, 36 in Ultimate Doom, and 9 in the shareware version (but the
shareware version does not allow pwads anyway).
Loading a wad file does not change the number of levels -- it merely replaces
or modifies some or all of the existing levels. Ones that do not get modified
stay the same as if you were running the original game (the IWAD, pronounced
eye-wad).
What it sounds like happened with your particular example is this:
Wad file 1: Wad file 2:
MAP01
MAP02
MAP03
MAP04
MAP05
MAP06
MAP07 !!! MAP07
MAP08 !!! MAP08 <- wad file 2 overwrites MAP07-MAP09,
MAP09 !!! MAP09 leaving only the first 6 levels of
MAP10 the first wad file.
MAP11
MAP12
MAP13
MAP14
MAP15
MAP16
MAP17
MAP18
In general, do not run more than one wad file at once, unless the wads all
come from the same package, or you know that they do not overwrite the same
resources.
Get a front-end if you want to make it easier to run several different wads.
>I can't get lmps to work right. > I got a program to convert them to my doom version, but after a >person dies and comes back to life, they appear in the wrong spots so >they are running against walls, and shooting walls. I hate this!! I >havent gotten 1 demo to work!(exept the ones that I made) > >Can anyone help to why this happens? and how to get them to play >corectly? > The reason this happens is the reason why they try to prevent you from running LMPs on different versions of Doom. It cannot be fixed. The reason is that LMPs record a series of virtual keystrokes, and play the game from scratch in real-time as though those keystrokes are being played by you every moment. If those keystrokes are played on a version of Doom or on a wad file that is even in the slightest different from the one that the LMP was recorded on, then the playback and the recording can become "out of sync" and the player will start walking into walls, shooting at thin air, getting killed without even trying to fight back, etc. Factors which can cause this to happen are: tiny differences in the walking speed a player takes each frame; differences in the lengths of lines on the map; differences in the behavior of monsters; differences in metrics (how high a player or monster is; what distances are required in order to walk through an opening or activate an object; etc.); the list could go on. You can sometimes get away with the trick of changing the version id of a LMP and playing it on your version of Doom even if it is not the same as the original, but sometimes you cannot. When you cannot, there's nothing you can do about it except contact the author and get a newer LMP (in case the LMP is old), or upgrade your version of Doom (in case your version is old), or remove a demo from a wadfile.
>I am running Doom2 in MS-Dos mode on a 486Dx33 machine with Win95 >installed (this shouldn't matter since I play in MS-Dos mode, right?). >I prefer to play in turbo mode but this doesn't seem to matter on some >levels where the game shows very sluggish responsiveness (i.e. the >weapons fire slowly, the marine responds slowly to mouse and keyboard >commands). On other levels, with the same settings, the action is >fast and responsive. Is this a function of differing amounts of >graphic detail from level to level or is this a problem with my >processor? Any suggestions as to config.sys and autoexec.bat settings >to alleviate this problem? Thanks. It could be a problem in the wads themselves. Try cheating with idkfa and then try shooting a rocket at a wall. If it goes through the wall, then it means the authors of the wad used a common but unnecessary and bad approach when creating their wad: they used 2-sided linedefs everywhere. As a result, even if the walls are not see-through, Doom must compute each one of them, as though the walls were see-through. If the wad authors used one-sided linedefs where possible, then Doom could simply stop rendering immediately when it reaches a one-sided line, thus making the game faster. The authors of one wad, which I will not name, admit that their wad is slow, but the reasons they give are wrong: it is not slow because it is a very complicated level -- it is slow because they used almost nothing but 2-sided lines, which makes Doom work much harder. 2-sided lines (even with the 2s flag turned off) do not stop plasma or rockets either, and they require much more work to process because they allow for the possibility of being seen through, and of objects on the other side of them being reachable. If you know about wad editing, simply look at the wad under an editor and see if it contains almost nothing but 2s lines. If so, then it's a poorly designed wad. The rocket test should tell you immediately, though. A good reject map may also improve playing speed.
>>>Hi, people!
>>>Maybe you can help me...?
>>>I'm building a WAD with DCK, nothing too complicated, since I am a beginner in
>>>the matter. There is a room in which I always get a "visplanes=xxx" error &
>>>bumping out to DOS, where xxx is a variable number (around 130). Other times
>>>it says "findplanes: No more visplanes", or things in that style. This happens
>>>when I look towards a certain direction, but not always in the same point. I
>>>guess the error means I'm trying to show too many planes or object faces at a
>>>time, but I don't think the room is that huge! i've tried simplifying the
>>>zone, but no help. DCK shows no error, anyway.
>>>I'd appreciate any help, I don't know what to do!
>>>TIA,
>
>>Visiplanes are a method Doom uses to simplify flat drawing. A
>>visiplane is a triangle-shaped horizontal plane leading from
>>a sidedef to the player, on either the floor or the ceiling.
>>Each sidedef that the player can see has a visiplane. A
>>visiplane stops when it reaches either the player or the
>>edge of it's sector (although not neccassarily, as you will
>>see if you read further on). A visiplane will not be drawn if
>>another visiplane already covers.....
>
>Ugh....
>It's not as complicated as everyone is telling you. You have too many
>two sided lineDefs in view. The room may not be large, but if you
>have a large staircase or something then that could be the cause.
>Sometimes just adding a large sector in front of wherever the error
>occurs will fix the problem... like a big platform or something that
>you can't see past.
>
>-Xen
>
Right, but I think it is more accurate to say that visplane overflows are
indirectly triggered by the player seeing through too many SEGMENTS at once.
Every set of two-sided linedefs which are parallel and coincident to a single
line, has at least one node line associated with it. A node line, whose length
is bounded only by a rectangle, may have many segments which are not common to
any linedef and these invisible segments can contribute to visplane overflows.
Using a different node builder, or tuning a node builder's heuristic so that
it tries to minimize the part of a node line inside the bounding rectangle
which is not already covered by linedefs, can reduce the chances of visplane
overflows.
If there are too many 2s linedefs which can be seen through at once, then a
node builder cannot do anything about it. But if the number of 2s linedefs
which can be seen through at once is just under the limit, then a node builder
can make or break a wad because it can add invisible segments that may cause
the limit to be exceeded.
/
I know this because I know of a wad that causes a visplane overflow, but only
when the player looks through an open door (not when they are standing in the
room with the door closed). This wad's visplane overflow problem was fixed by
using a different node builder, and I later found that retuning the heuristic
of the original node builder which caused the problem also fixed it. Using a
node navigation program, I saw that the wad with the visplane overflows had
more node lines in view at once when the player was looking through that door -
node lines which went into the middle of the room, but which did not have any
linedefs nearby that the player could even see.
/
nodeline
>two sided lineDefs in view. The room may not be large, but if you
>have a large staircase or something then that could be the cause.
I have successfully created staircases with over 1000 steps. I'd be glad to
share with you the math I used to prevent the visplane overflows.
>can anyone help me with this. my level is based on the marina.wad but i
>expanded it quite a bit. i read on faq that said something about light
>levels but mine are all the same. none of the linedefs are over 1024. i
>thought maybe the nodebuilder was at fault (im a bit of a newbie) so i
>changed editors (windeu=>deep) but got the same error. i even tried
>cutting out part of the area, but still the same thing. if anybody has
>any ideas please reply, thanks.
Try decreasing the number of 2-sided linedefs that are in view at any
moment. Despite what everyone says about light levels, line lengths,
floor textures, etc., I think the single most important factor (but not
exclusively) which causes visplane overflows is the number of node segments
that the player sees through at any one moment. Other factors may exist, but
the easiest way I've found to reduce visplane overflows is to reduce the
number of 2-sided linedefs that the player can see through at any particular
moment anywhere on the map. Those linedefs are divided up into segments by
the node builder to make convex SSECTORs, and so your intuition about node
builders is correct.
As for node builders, try BSP20x. I added the -factor option to
BSP because of a visplane overflow problem that I found could be
corrected by playing around with the nodes. Try BSP20x using -factor 10,
then -factor 5, and -factor 1. Smaller values sometimes tend to reduce the
chances of visplane overflows, but they also lead to larger wads because
they allow more line segments to be split. But I make no guarantees that
BSP20x or any other node builder will fix the problem -- some wads have
just too many 2-sided linedefs for the node builder to make any difference.
If you have a lot of sectors with lots of different heights, try reducing
the number of height changes by, say, reducing the number of steps in a
flight of stairs, or simplifying the structure of an object that sits inside
a large room.
If you have a large, wide open room with lots of sectors in it, try to trick
the node builder by splitting the room into small sections separated by
2-sided linedefs that are totally transparent (-). The worst thing that can
happen and will cause visplane overflows is for the node builder to do
something like this (numbers refer to sectors):
--------------------------
| 1 node line |
| - <---> - |
| |2| |3| |
| - <---> - |
| node*line |
--------------------------
Those arrows are node lines that the node builder generates, not lines you
created. The only lines you would create in the figure above are the 12
lines making up the outside of the room and the four sides of each of the
two sectors labelled 2 and 3.
If the node builder generates node lines as indicated above, it will cause
the player to see through two invisible node lines when they are standing at
the position indicated by * in the bottom of that figure. What you want the
node builder to do instead is this:
--------------------------
| 1 ^ ^ |
| -| |- |
| |2| |3| |
| -^ ^- |
| | * | |
--------------------------
| |
^ node lines ^
That way, the player does not see through anything down the middle of the
room, since the node lines are off to the sides.
You can sometimes trick a node builder into doing what you want by adding
lines yourself:
--------------------------
| 1 | 4 | 5 |
| -| |- |
| |2| |3| |
| -| |- |
| | * | |
--------------------------
It seems ironic that increasing the number of sectors like this can help,
but it might actually work, since the node builder will then sense that it
is better to choose those vertical lines you added as the node lines, and
this will prevent it from cutting the player's view with several node lines.
Actually, you might just want to add 2-sided lines without actually spliting
sectors, since this might do the job also. Node builders generally try to
avoid splitting lines, so if you can add extraneous lines in such a way that
the node builder would be splitting them if it chose the wrong node lines,
then it might work.
A node builder must split a map into nothing but simple-sectors. A simple-
sector is never more than any sector you create, but a sector you create may
be broken up into ssectors. Each time sectors are broken up they are broken
up by choosing a node line to divide the "universe" into two halves.
From my empirical research I have found that node lines can contribute to
visplane overflows in the sense that they are caused by how many node lines
the player is looking through at any moment. To prevent visplane overflows
you want the player's view to be cut by as few (invisible) lines as
possible. In a large room with many sectors of varying heights scattered
around, the node builder might choose a node line which cuts right through
the middle of the room, and if there are many cuts like this, it can add up
to visplane overflows.
I think the confusion out there about differing light levels or
floor/ceiling textures causing visplane overflows is simply the result of
the fact that many node builders will merge identical sectors, and as a
result, the lines that it deals with are different, causing it to build the
BSP tree differently than if the light levels or floor/ceiling textures were
all the same. If they are all the same, then some node builders will merge
the sectors and make the room simpler and there will be fewer lines. But I
think floor and ceiling height differences (not the number of different
textures or light levels), and the number of 2-sided linedefs, can
contribute towards visplane overflows.
By the way, if you are trying to create long staircases and are getting
visplane overflows, I have created staircases with over 1,000 steps and no
visplane overflows.
Try BSP20x, available at:
ftp.cdrom.com:/pub/doom/utils/level_edit/node_builders/bsp20x.zip
PS. Some more recent insights on visplane overflows:
The HOM sometimes seen at a far distance is due to the number of linedefs
that can be drawn at once. I am currently working with someone on a wad that
has these problems, but only when certain doors are open. The reason, as
best as I can tell, is that when the door opens, Doom starts drawing more
lines and this causes an internal limit to be reached much more quickly,
causing lines farther out to start becoming HOM-like. I have not found a
way to fix it simply by changing the map, without keeping the doors shut all
the time, although I have been able to reduce the problem by tuning the node
builder.
Visplane overflows and HOM can be caused by differing light levels, but they
also depend, and I think much more, on the way the nodes are built (hence,
you can tweak the node builder and sometimes remove or reduce these
problems), and on the number of 2s lines, and other lesser factors.
>can anyone tell me how you apply the wall texture that give you an >"unattached" sky effect (cityscape, mountainscape and clouds)? If you simply mean you want to use the "floating" sky (that's the official term), which looks somewhat realistic, then you simply need to make the ceiling of your sectors F_SKY1. F_SKY1 is a special kind of ceiling texture which actually comes, as you suspect, from the SKY1, SKY2, SKY3 wall textures, but Doom makes them "floating". Which one (SKY1, SKY2, SKY3) is chosen depends on the level, and rotates from level to level (you cannot change this without hacking the .EXE file). So simply make your ceiling texture F_SKY1, and you will see the sky. >I've checked out levels on Doom II but can't see how it's done. All >the places where the 'scapes appear have a sector with a lower >ceiling than the ajacent sector and no upper texture. No sign of the >appropriate wall texture (SKY1, SKY2 or SKY3) though. Look at the ceiling textures for the sectors that surround those buildings. It is F_SKY1. If two adjacent sectors both have F_SKY1 as their ceiling texture, then no matter what the upper textures are (or even if they're missing), a sky will be drawn between the two sectors' ceilings and it will look like there is no difference (still the same sky). Therefore if you want to make buildings of different height, simply contain a building within a separate sector, and make the ceiling height of that sector the height you want the building to be. No upper textures are needed, because if both that sector and the one outside of it have F_SKY1 ceilings, then it will be nothing but sky that is drawn between them.
> Okay, I'm cooking. Got a WAD sorted out. Recognize all the effects when things
>go wrong. Starting to write some decent levels. Two things stop me, however..
>
>i) How do I give a door a ceiling ie a frame. I can do the side frame bits but
>not the top bit. How can I do this- it looks a bit strange with the door going
>all the way up to the ceiling
You can put another sector "in-between" the door:
DR door type linedef
\/
---------------------------
| sector 1 |
| |
---------------------------
| sector 2 | <- make the ceiling height of this sector
--------------------------- the height you want the door to go up to
| |
| sector 1 |
---------------------------
/\
DR door type linedef
What you need to do is make sector 2 have a ceiling height equal to the
height you want the door to open up to (actually, the door will open to 4
pixels lower than it). Make the linedefs in sector #1 shown above all have
sidedef references to sector 1, so that both halves of the door which are
split still make up the same sector, so that when the door is activated on
either side, both sides open. If this is too hard for you to do because
your editor makes it hard for you to create unconnected sectors like this,
then there is an alternative way:
SR door type linedef, tag=x
\/
---------------------------
| sector 1 tag=x |
| |
---------------------------
| sector 2 | <- make the ceiling height of this sector
--------------------------- the height you want the door to go up to
| |
| sector 3 tag=x |
---------------------------
/\
SR door type linedef, tag=x
In this case, you need to make the door linedefs have a "switch" door type
instead of a normal door type, and you need to tag both linedefs with both
sides of the door (sectors 1 and 3).
(Actually, sectors 1, 2, and 3 in the above examples can be any sector
numbers -- this is just an example).
Yet another way to do it, if it looks strange being broken in the middle
like that, is to put the sector on the outside, like this:
------< DR door type linedef
/ \/
| ---------------------------
| | 1 |
| | |
-> ---------------------------
| 2 | <- make the ceiling height of this sector
--------------------------- the height you want the door to go up to
In any case, the rule to remember is this: when a door is opened, it
raises the ceiling height of the affected sector(s) to 4 less than the
lowest ceiling height of the sector(s) adjacent to each of them. By putting
a "buffer" sector near the door with a lower ceiling height than the
surrounding room, you can make the door open to a height lower than the
room. You can make the buffer sector very thin, almost invisible, too.
>
>ii) If I make a door and put a texture on it, the texture is too big for the
>door and not all of it is shown. How do I adjust this?????
>
You can use the y offsets. The y offset, which is specified in a sidedef,
tells Doom where, modulo the texture size, to being drawing the texture. Door
textures, like all upper textures, are normally drawn bottom-up, but you can
make them draw top-down if you set the "upper unpegged" flag. But if you set
the "upper unpegged" flag on a door, then the door will look funny when it
opens because it will appear to "roll up" rather than actually move up.
Key points: door textures are upper textures that are normally drawn
bottom-up, but can be drawn top-down if the upper unpegged flag is set. In
any case, the sidedef's "y-offset" can be used to adjust where exactly the
texture starts being drawn.
>iii) Finally (I know I said it was two.....), how do I make a window to look
>out onto the red sky and mountains?????????
Create a buffer sector connected to the wall:
_________________________ <- make this line have a normal
| | texture of SKY1, SKY2, or SKY3
| buffer sector | or any other texture you want.
-------------*-------------------------*----------------
^
|
make this line "upper unpegged", "lower unpegged",
and make its upper and lower textures the same as
the adjacent wall texture, but leave the normal
texture blank (i.e. "-").
Make the buffer sector have a floor and ceiling height that you want the
window opening to have. Make the line on the other side of the sector have a
SKY1, SKY2, or SKY3 texture, or any texture for that matter.
Note that this creates a "static" sky texture, which is like a picture. If
you want a "floating" sky, which looks the the sky outside when the player
moves around, then it's a little more complicated:
--------------------------------------------------------
| Make this sector have F_SKY1 ceiling |
| |
| |
-------------*-------------------------*----------------
| buffer sector |
-------------*-------------------------*----------------
In this case, you still need to make a buffer sector for the window, with
floor and ceiling heights to set the heights of the opening, but you need a
sector on the opposite side, with a ceiling texture of F_SKY1. The ceiling
height of that sector can be made very small in order to make it all look
like sky. If you want, say, a lake outside, then you can set the floor
texture of that outer sector to have a F_WATER1 or other floor texture.
There are other special tricks you can use to make the picture look better,
but I do not have time to go into the details, which are complicated (they
require at least 3 more lines to be added, as well as careful positioning
and alignment).
One thing to remember about F_SKY1 ceiling textures: Whenever two sectors
separated by a common linedef have F_SKY1 as their ceiling texture, then no
matter what the ceiling height differences are between the two sectors,
upper textures are always drawn as floating sky textures. Another way to
think of it is that the upper textures are not even drawn. This property
allows you to construct outdoor buildings of different heights, by enclosing
the buildings inside sectors of different ceiling heights, but with F_SKY1
as the ceiling texture:
-------------------------------------------------------------
| ---------------------------- 1 |
| | buffer sector | |
| | ------------------- | --------------------- |
| | 2 | 3 building A | | | 4 building B | |
| | ------------------- | --------------------- |
| | ceiling=F_SKY1 | main sector |
| ---------------------------- ceiling=F_SKY1 |
-------------------------------------------------------------
Numbers refer to sectors. Sector 1 is the main outside sector, with F_SKY1
ceiling. Sector 2 is a buffer sector, with F_SKY1 ceiling also, but with a
smaller (or larger) ceiling height. Since both sectors have F_SKY1 as their
ceiling texture, there is actually no "upper" texture drawn on the lines
separating sectors 1 and 2. This allows building A's height to be set
independently of building B's. Building A's height will be set to the
ceiling height of sector 2, while B's height will be set to the ceiling
height of sector 1. No differences in ceiling heights will be noticable
because of the special way F_SKY1 works.
For more information, I suggest you read Scott Amspoker's FAQ on textures,
located at ftp.cdrom.com:/pub/doom/docs/textures.doc (I think that's
right...). It will explain to you all about y offsets, unpegged attributes,
F_SKY1, etc.
>Is there a file size limit to WADs? I am modifying a WAD and when I run >Doom with the new WAD, it begins okay, but I begin to play, and it crashes >and gives me an error of something like "cacheNumLumps >= NumLumps" or >something like that. Has anybody else experienced anything like this? > >Does anyone know where I can get a good DOOM 1 to DOOM 2 wad converter. >The one I use only does graphics. DM2CONV does conversions pretty well. Note that if you want exact conversions, then you need to use the graphics program that accompanies it, and you might also have to change the response files so that the conversion does not change any Doom 1 Things into Doom 2 things (by default, it randomizes so that, say, half of the Barons get converted to Hell Knights). I have a response file already that tries to make the conversion as exact as possible. If you want to convert your entire Doom 1 IWAD (the original game) into a Doom 2 PWAD, this is also possible, except that secret levels and sky textures will not be the same (nothing can be done about this, without changing DOOM2.EXE). I wrote a .BAT file that uses DEUTEX and DM2CONV to convert your supplied DOOM.WAD (iwad) into a pwad for Doom 2. Try DM2CONV, but remember to experiment with the response files (.RSP) to control exactly how the conversion takes place. >what is a *.wad file and how do you use it? A wad file is composed of "lumps" and a directory that lists them. Each lump has a name and a piece of data -- in a way, wads mimick directories and lumps mimick files. I have seen wads in other games besides Doom, but most of them are made by either Id or Apogee. A wad file does not work the same necessarily in those games -- but a wad is still a wad. In Doom, there are two kinds of wads -- Iwads and Pwads. Iwads are the ones that come with the games, like DOOM2.WAD in your Doom 2 directory. An IWAD defines a complete game. Pwads, which are all the wads that everyone talks about downloading and making for themselves, are "Patch wads". They modify certain aspects of the game without totally replacing it. Most commonly in Doom pwads, the game's levels are replaced, so that new buildings, new monster arrangements, new secrets, etc. appear. To use a doom pwad, simply run Doom or Doom 2 with the -file switch: doom -file wadfile.wad wadfile2.wad wadfile3.wad ... doom2 -file wadfile.wad wadfile2.wad wadfile3.wad ... The "..." indicates that an arbitrary number of wad files may follow the -file switch. Usually only one will be used, as in: doom -file onewad.wad Since pwads replace only parts of the game (well, some pwads replace nearly everything, but they are still technically pwads), they may seem to have no effect sometimes on the game, because they might only change one level out of ~ 30 levels, or they might only change the music, etc. Nearly all wads that are not simply music or sound effects wads, replace at least one level, though. The shareware version of Doom 1 does not allow pwads, so you must register Doom to use pwads. Much older versions of shareware Doom allowed it, although Id Software asked no-one to use pwads in the shareware version. As a result, most level authors intentionally made their levels unplayable on the shareware version, by adding Things like plasma guns, which only appear in the registered version and cause the shareware version to crash. Long answer, I know... Simply type something like: doom -file wadfile.wad and have fun.
>What causes the problem where bullets and/or projectile weapons appear to go
>through walls (i.e., there is no impact frame)? Is there any way to fix it?
If you make your wall linedefs have 2 sides, then even if you cannot see
through them, and even if they are impassable, bullets and other weapons
still go through them.
You can stop bullets from going through two-sided lines by turning off the
"2s" flag, while still leaving two sidedefs with the line. A line can have
two sidedefs but still be "not 2s", in which case bullets will not go
through them, and no-one can see through them, but plasma and rockets (which
are called 'projectiles') can still go through them.
The only way to complete stop all weapons, including rockets and plasma,
from going through walls, is to use true 1-sided linedefs, or to make the
floor/ceiling height differences of the two joined sectors large enough so
that either the upper or lower texture is all that is seen.
Make sure that you use walls like this:
_________________________
|
hall near room
___________|_____________
____________________ <- small gap of "null space"
| | | separates the two areas and
| | prevents things from flying
|_ room _| through walls. A door or a small
| | hallway can be added to connect
| | them.
|_________|__________|
Instead of:
_________________________
|
hall near room
_________________________ <- a 2-sided line separating rooms can
| | | always be shot through in some way
| | if the normal (middle) texture is
|_ room _| viewable, since rockets and plasma
| | can always go through normal textures
| | of lines with 2 sides defined for
|_________|__________| them, and bullets can go through
those which have the 2s flag turned
on.
In even more rare circumstances, there is a bug either in Doom or in the
nodebuilder which causes this to happen on lower textures, like near the
plasma guns on MAP16 of Doom 2. When this happens, the cure is usually just
to flip the linedef so that the right side points out.
(comments based on an actual wad)
A linedef has a left side and a right side. The left and right sides are
defined based on where they would be if you were looking at the ending vertex
from the starting vertex. Most editors (all decent ones) indicate the right
side by hanging a perpendicular ( |- ) on the right side.
Your wad had 2-sided linedefs for all but the outermost and innermost building
walls, even though they looked like they should be one-sided since there are,
in keeping with this assumption, two walls for each room, an inside one and
an outside one. This is normal, correct practice in wads. What is not correct
is that these walls should have 2-sided linedefs, which they did in your wad.
In the Doom literature, a linedef is called 2-sided if it has two sides
defined for it, regardless of whether the "2-sided bit" is turned on.
A line can have two sides and still have the 2-sided bit turned off, in
which case monsters cannot see through it and bullets cannot go through it,
but rockets and plasma can go through it.
If it is your intention to create a deatchmatch wad where each player fires
rockets or plasma at each other through the walls without being able to see
their opponents, then I'm sorry -- simply change the wall linedefs to have
any textures for their second sidedefs, but leave the 2s bit turned off.
If a linedef has only one side, then it must be the right side. Almost all
of your linedefs had to be flipped in order to satisfy this requirement.
If a linedef has only one side, then nothing at all can go or see through it,
and any attempt to use see-through textures will result in HOM (Hall of
Mirrors).
If a linedef has two sides and has the 2s bit turned on, then its middle
texture can only be from a single patch. Otherwise Doom slows down > 10 times
when the player looks at it (this is known as the Medusa effect). Actually,
Medusa does not occur unless two or more patches make up the visible part
of any column. As long as no patches share the same column in the visible
part of the texture, Medusa does not occur. The SKIN textures of Doom are
examples of textures that are multipatched but still work as normal textures
of 2s lines.
One of your doors was left open because its ceiling height was the same
height as the surrounding rooms. I changed it to make it have a ceiling
height of 0 so that it would start off closed and operate like all of the
other doors.
The doors in a few of the rooms had their linedefs backwards just like all
the other linedefs. For doors which are activated by the spacebar, this is
really a bug, since those doors must always have their right sides facing
outwards in order to work properly. Doors and other "grab"-activated effects
must be oriented such that the player sees and touches ("grabs") the right
side of the linedefs. If a door's linedefs are backwards, it can cause strange
effects -- the door will not open or shut normally, but if you press on the
spacebar while standing inside the doorway while the door is open, then you
will "open" or "close" the entire room just outside of the door, which
usually has no effect since its ceiling height is already the highest one
around. The net result then is a door which makes a sound from an odd
direction, but no movement.
About half of the door tracks did not have the lower unpegged attribute,
and so their textures moved with the doors during opening and closing. This
is a matter of preference.
Your wad had the same sectors referred to in many different rooms. While
this might work in some cases, it is non-standard practice and is error-prone.
Do not use the same sector to refer to rooms which are not touching. If one
area should not be seen from another area at ANY time (such as when a door
is closed), then the two areas should have different sectors. Only use the
same sectors for multiple areas if they are connected and the player can
always walk from any part of the area to another. Don't, for example, use
the same sector for rooms separated by a door.
Some of the sectors were not closed, which caused the invisible barriers.
I noticed that in one hallway, right next to a door, it was impossible to
walk to the door:
door
___________
hallway
barrier -----------
| |
| |
| |
When I turned on no clipping mode to walk through that barrier, I noticed
that the door split in half. This is consistent with the sectors not being
closed, confusing the Doom engine as well as the blockmap builder that
generated the barrier.
Your linedefs should be changed to truely 1-sided linedefs, not 2-sided
linedefs with the 2s flag turned off, unless: you want rockets and plasma
to go through walls; and, you don't mind most consistency checkers reporting
errors in your wad even though it works okay.
You need to make sure your sectors are closed, and you should not use the
same sectors for rooms which can be on opposite sides of a door or any
other sector whose floor and ceiling heights can change. Otherwise, problems
like invisible barriers, Doom crashing, and other strange things can happen.
>There is a bug in Reject Map Builder v1.1.0 which is when you use it on a >Pwad it makes mosters float . I don't know why this happens , but I do know >that when I used it on a PWAD and then played a different PWAD the monsters >where floating in it . I was woundering if anybody knew why ? Dose RMB use >your main IWAD when building ? I don't know , but do want to know , what is >going on . Thanks I think what you mean is that the Things appear on the ceiling rather than the floor, and there is an invisible barrier around the area they are elevated on. This occurs with node builders and perhaps RMB too. You can work around it, at least, by adding linedefs to your map around the area that they float on. When playing the game, try to notice where the invisible barrier is, and then under an editor, add a line to match that barrier, but make the line 2-sided and never on map, and split the sector in half so that there are two sectors now. This trick should not affect game play one bit but it seems to work around node builder problems. In general, add extra, non-functioning linedefs to the map where it is having problems, and this will usually cure the problem because the node builder or other program will now have a totally different picture of the nodes (which look nothing like the map, although they compose it). About the IWAD: I do not think RMB needs your IWAD, except maybe to protect against using it on shareware versions.
>With regards to buildings of different heights, I mean, can I have one building >128 high and another building say 400 high without having the wall that encloses >the entire wad be or look 400 high. It sounds simple enough but when I tried it, >it looked all messed up. If you are talking about buildings in the context of a sky ceiling, such as Doom 2's Downtown level (MAP13), then it is possible to do what you are asking. Simply enclose around the building a sector whose ceiling height is the height you want the building to be, but make the lines "never on map". Make both this sector and the one outside of it have F_SKY1 ceiling texture (this is important). Make the lower and normal textures of the lines "-" and don't worry about upper textures (Doom says "don't care" about upper textures when both sides of a line are on sectors with F_SKY1 ceiling texture). Example: ----------------------------------------------------------------------------- | outer sector; any ceiling height will do; just be sure to use F_SKY1 ceiling| | ceiling height determines the outer walls' height. | | ------------------------- ------------------------- < | | | ceiling=F_SKY1 | | ceiling=F_SKY1 | \_ linedef | | | --------------- | | --------------- | <- "never on | | | | Building 1 | | | | Building 2 | | map" and | | | --------------- | | --------------- | textures | | | height=height of bldg 1 | | height=height of bldg 2 | are all - | | ------------------------- ------------------------- | | | ----------------------------------------------------------------------------- When a one-sided linedef is used for a building's side, the building's height is determined by the ceiling height of the enclosing sector around the outside of the building. When a two-sided linedef is used, the height of the enclosing sector also matters, since it determines how much, if any, of the upper texture is used, but so does the adjacent sector also. This is how windows can be created in tall buildings, such as in Doom 2's MAP13. A sector surrounds the building to set the height of its top, and then the building is drawn with 1-sided linedefs for normal walls, and 2-sided linedefs for doors and windows. The whole building is drawn as if it has the height of the sector it is totally contained within. It is important that both this containing sector and any other adjacent sectors, such as ones for other buildings, have F_SKY1 as their ceiling texture. When two sectors both have F_SKY1 as their ceiling texture, then no matter how their ceiling heights differ, they appear to be one big "sky" of the same height because any upper textures that would normally be defined by the sidedefs of the joining lines are ignored and displayed as simply part of a larger sky. You do not need to set the ceiling height of the entire level to 400 or anything like that, because as long as two sectors have the sky ceiling, lines that join them will not have any upper textures drawn and the sky will look, well, as high as the sky! The illustration above is very general; you do not even need an outer sector necessarily unless you want to erect a fence/wall around the level and be able to set its height. For two buildings, you only need two enclosing sectors, not three. Of course, if you never need to walk into or out of the building -- only teleport in or out of it, or jump onto its top, then raising the floor height is the simplest way to go.
>What I finally did to fix it was make independent sectors out of each of >the columns, still with the same >floor\ceiling heights, then assign the tags from the original six sectors >to the twelve new ones. >I also had to put small sectors, with floor heights to match that of the >bottom floor, inside each of >the new sectors, so that the new sectors' floors would continue to drop and >not stop when the reached >the level of the floor they were located in. Functionally, it's the same >as before, but now DCK >and/or the game engine isn't confused any more. I've also used this trick of making unconnected regions have the same sectors, but as you have noticed, it is risky. I have never heard of such a problem as you were having, which makes me think it may be due to the node builder. Remember when using this trick that sound travels through the sector, so that if you make a sector unconnected but in several rooms, then monsters in every room with that sector can hear monsters in other rooms (unless of course block sound lines override this). In general here's my advice on using unconnected sectors: Do not make a sector unconnected if: 1. The unconnected regions are in rooms separated by doors or other activated devices, so that visibility between the two unconnected regions can change during the game without the player or other Things moving except as per floor height. In other words, the unconnected regions should not be separated by a lift, door, crusher, etc., and become visible or invisible with each other based on activating a linedef. 2. You do not want sound to travel between the sectors. Even if the sectors are in rooms separated by closed doors or are totally isolated, sound will travel as though the rooms are connected, if the same sector is used. 3. A Thing is in one of the sectors. This is the problem you just experienced. Doom bases the height and movement of a Thing on the sector that the Thing resides in. All of these reasons may be dismissed from time to time, if you want to do special effects. For example, I recently made a bathtub special effect that lets the player walk into a bathtub, press a switch to make it fill up with water, and press the switch again to empty it. The player also wades in the water while it is filled up (the deep water effect, where the height of a Thing is lower than the height of the floor texture). This special effect uses a lot of unconnected sectors. Another reason your floor lowering trick might not have worked is if the sector being activated touched another sector that was moving. Doom seems to get confused if two sectors being lowered with the same tag are adjacent. It's sort of like a 'race condition' between the two floors to see which one is actually lower -- As soon as one is activated, it must figure out which adjacent one it should move towards, and if one of the adjacent ones was also triggered and is moving, then Doom may have a hard time figuring out what floor height to lower the sector to.
> i've been working on a new small wad, but keep getting bigtime homs. >What can I look for as a possible cause. In part of the wad I have made maze >that u walk thru plus it has sniper spots that over look the maze HOM can be caused by: 1. Missing upper and lower textures on 2s lines when there are ceiling and floor height differences, respectively (except when both sectors have F_SKY1 ceiling in which case upper textures do not matter). 2. Missing normal textures on one-sided lines, or lines with 2s flag turned off 3. Too many lines in view at once Sometimes a wad will act strangely if there are overlapping lines, and you will not even be able to see them because they are completely overshadowed by another line. Sectors not being closed usually does not affect textures or cause HOM -- it usually only affects Things, although a sector not being closed may be an indicator that a wall texture may not be drawn correctly and may have HOM, if the sectors on either side of it seem fishy. Except for missing textures, including ones that are hidden in overlapping lines, I cannot think of anything that would cause HOM in a small wad.
>I'm curious about this "deep water effect." I've seen it
>mentioned in the NG, but don't know how it's done. I must be more of a
>newbie than you think, since your description above doesn't make sense to me.
>How do you get a Thing to stand_below_ the floor level?
The deep water effect is, surprisingly, one of the easiest special effects
to do and it does not depend much on the node builder used (unlike transparent
doors and some other effects).
Example:
3
---------------------------------
| 2 |
| |
| 1 |
| -------------------- |
| | 1 | |
| | | |
3|2 1|1 Thing 1|1 2|3
| | | |
| | 1 | |
| -------------------- |
| 1 |
| |
| 2 |
---------------------------------
3
The numbers refer to sidedef sector references. A sector in Doom is defined
totally by sidedef references, which in turn are referenced in linedefs. A
sector only has a floor height, ceiling height, type, tag, etc., but no
position, at least not exactly.
Whenever a series of linedefs inside of one sector have sidedef references to
a different sector with a lower floor height, but on both sides of the line,
then that sector's floor height determines the height that Things are at
inside of it, while the outer sector sets the height of the floor and ceiling
textures. In-between the two sectors the floor height that Things rest on is
determined by the outer sector's floor height. If you make the area between
the inner and outer sectors as small as possible, then you can make the
inner sector almost totally determine the height at which Things will be
drawn from inside.
In the example above, sector 2 is the sector that defines the floor height of
the floor texture that is drawn. Sector 1, however, can have a lower floor
height, but since the linedefs making up sector 1 refer to sector 1 on both
sidedefs, the floor and ceiling are still drawn according to sector 2's
heights, even though a Thing may be at a lower height inside sector 1.
Lets say you wanted to hide a megasphere or some other Thing "underground" as
a secret. Then you could simply create a series of nested sectors like the
above drawing, such that the first sector inside the outermost one has lines
with both sides referring to the same sector. As long as the first one inside
the nest has both sides of its lines referring to the same sector, the floor
will be drawn at the height of the outermost sector, regardless of whether the
lines deeper inside the nest have both sides referring to same sectors or not.
By making these nested sectors, you can create "steps" down to the Thing. Each
step can be no more than 24 units, or else the player will not be able to get
back out.
I am working on a wad right now with someone else and I am adding this special
effect to put keys and other items (like a megasphere) underground, underneath
a street. A manhole cover on the street looks rather flat, but actually, if
you walk across it just right, you (a Thing) can fall to a height lower than
the street, and can pick up another Thing (the megasphere), which is normally
invisible due to the deep water effect. In this case it has nothing to do with
water but it's based on the same idea -- namely, that Things can be at lower
heights than floor textures, if a sector containing the Thing(s) is made up of
lines that have both sides referring to the same sector, one with a lower floor
height than the one it is contained in.
The trick is that sector 1 in the drawing above is made up of lines that have
sector 1 on both sides, while no lines directly connect sectors 1 and 2. As
a result, Doom simply draws sector 2 as if it were one big sector without any
others inside of it, for floor texture drawing purposes, but when it comes to
Things, then the inner sectors' floor heights matter.
>how do you make the arrangement thats cause power up's and monsters >to appear only in the level "Im too young to die"? The way to make items change from skill level to skill level is to change the flags in the Things. Every Thing, be it a monster, pillar, dead body, ammo, weapon, etc., can be programmed to appear in skill levels 1&2, 3, or 4&5, or any combination thereof (but if it appears in skill 1, or it doesn't, then the same must be true of skill 2, and similarly between 4 and 5). It is also possible to program a Thing to appear only during multiplayer games. Unfortunately, a Thing cannot appear in single-player games and NOT appear in multiplayer games -- if it appears in single-player games then it must appear in all games. The only way I know how to make an item available only during single-player mode is to block it with a pillar or other object, and to make that object only appear during multiplayer games. That way, if the game is single-player, then the blocking Thing does not appear and the player can reach the one behind it.